Hi Tom,
Yes my G2 arcs are other way around. This has
to do with Mach3 "arcs reversed in front tool post"
Arc should be under the threading pass
Extra motions, namely the the Y-axis moves are for
tool position changes since it is a gang tool lathe.
My Mach Elapse time Dro says 46 sec (occasionally
-07:-30) or something else equally absurd), true stopwatch app. 38
sec
Arc is fast because of G95-feed per rev =
5mmx1000rpm = rapid move
I reattach the Gcode, I edited out all toolchanges,
Y-moves and system specific Mcodes. I also changed the G2's to G3 so that thay
should be correct in your system.
After my previous post I made two videos of the
workcycle with both buffer settings.
Unfortunatelly the videos were taken with samsung
S7, resulting to 60MB files that I can't upload to group/Files/my folder because
of the 10MB limit.
For some odd samusung reason the picture is also
sideways.
Also noticed that my XP pc with intel celeron can't
play back smoothly so atleast on my screen the delay is not as clear as in real
world.
Is there anywhere else I could upload
them?
| Group: DynoMotion |
Message: 13341 |
From: Tom Kerekes |
Date: 6/10/2016 |
| Subject: Re: Mach3 lathe threading [1 Attachment] |
Hi Tapio,
Thanks. That is simpler and looks correct. But I still don't
see an abnormal delay. Mine runs in 14 seconds regardless of the
Buffering.
Consider uploading to Youtube. They are pretty good about
handling and fixing most formats.
Regards
TK
Hi Tom,
Yes my G2 arcs are other
way around. This has to do with Mach3 "arcs reversed in
front tool post"
Arc should be under the
threading pass
Extra motions, namely the
the Y-axis moves are for tool position changes since it
is a gang tool lathe.
My Mach Elapse time Dro
says 46 sec (occasionally -07:-30) or something else
equally absurd), true stopwatch app. 38 sec
Arc is fast because of
G95-feed per rev = 5mmx1000rpm = rapid move
I reattach the Gcode, I
edited out all toolchanges, Y-moves and system specific
Mcodes. I also changed the G2's to G3 so that thay
should be correct in your system.
After my previous post I
made two videos of the workcycle with both buffer
settings.
Unfortunatelly the videos
were taken with samsung S7, resulting to 60MB files that
I can't upload to group/Files/my folder because of the
10MB limit.
For some odd samusung
reason the picture is also sideways.
Also noticed that my XP pc
with intel celeron can't play back smoothly so atleast
on my screen the delay is not as clear as in real world.
Is there anywhere else I
could upload them?
| Group: DynoMotion |
Message: 13342 |
From: Tapio Larikka |
Date: 6/11/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tom,
Please excuse the instability in 3 sec video,
caused by chip hitting the camera man in the face.
I tested running in simulation and it does not show
same delay as in real world.
From what I have read on various posts this delay
in threading is present with most external controllers,
Threading starts at 1:38
I usually use G76 macro for threading, for the ease of tweaking the
measurements when needed, but several cross checks show no difference in
time/delay,
so the delay is not due to mach3 macro handling.
Regards,
Tapio
| Group: DynoMotion |
Message: 13344 |
From: Steve Blackmore |
Date: 6/12/2016 |
| Subject: Re: Mach3 lathe threading |
On Sat, 11 Jun 2016 12:32:46 +0300, you wrote:
>Windows buffer time 3 seconds: https://youtu.be/uGlA17TFJV4
>Windows buffer time 0.4 seconds: https://youtu.be/WifaMpSrTb4
>Please excuse the instability in 3 sec video, caused by chip hitting the camera man in the face.
>
>I tested running in simulation and it does not show same delay as in real world.
>
>From what I have read on various posts this delay in threading is present with most external controllers,
>this threading with mach/Galil: https://www.youtube.com/watch?v=JfnQxDPWoEQ being only exception I have found
>Threading starts at 1:38
Comparing apples to oranges there I think, the Galil uses Ethernet, not
USB so buffer refresh rates are considerably quicker.
>I usually use G76 macro for threading, for the ease of tweaking the measurements when needed, but several cross checks show no difference in time/delay,
>so the delay is not due to mach3 macro handling.
Try it with G32 not macro.
Mach3 as with most other controls uses the index pulse as the timer for
the start of the threading pass. It waits for the next pulse before
issuing the next line. (From discussions a while ago and a fading
memory- that might actually be two or three pulses to ensure no false
trigger).
The thread pitch, diameter, spindle speed and lead in distance all
affect the delay to some degree also.
Looking at your videos that looks normal for a USB control with Mach.
Steve Blackmore
-- |
|
| Group: DynoMotion |
Message: 13350 |
From: Tom Kerekes |
Date: 6/12/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Steve/Tapio,
I think the Galil might be a pci/isa card actually.
Tapio is using G32 and said it behaves no different from G76
I shouldn't have said I was "simulating". The test setup is
actually moving/driving motors on the bench. I just don't have a
real Lathe connected. So the timing should be real.
Actually with our Plugin an A/B quadrature encoder signal is used
not an index pulse. But regardless there will be a fraction of
one rotation delay to sync to the Spindle angle for each pass.
But at 1000RPM that should be less than 60ms.
I did some investigation and wrote a KFLOP C Program to monitor
and time the start/stops of coordinated motion to measure the
amount of dead time. See attached. There is a small difference
with regard to the buffering (we could probably address that if
necessary). But the main delay seems to come from Mach3. It
only calls the plugin 10X per second (~100ms each). When one pass
or motion ends and we tell Mach3 everything is complete until
Mach3 starts giving new motion data there are about 3~4 calls with
no data. That results in a few 200~300ms delay deltas shown
below. I don't know what Mach3 is waiting for. Ironically a bug
inadvertently introduced that hogged a lot of time in our Plugin
caused the times to go down somewhat, but that caused other
problems such as the Mach3 GUI didn't update.
Mach3 (0.3 sec buffering)
Start = 0.000000ms Delta = 0.000000ms Total = 0.000000 Indx=5
Start = 1094.041720ms Delta = 804.068140ms Total = 804.068140
Indx=1
Start = 2631.871700ms Delta = 537.756480ms Total = 1341.824620
Indx=12
Start = 3505.052300ms Delta = 259.206660ms Total = 1601.031280
Indx=5
Start = 5260.591660ms Delta = 255.425660ms Total = 1856.456940
Indx=5
Start = 7000.471740ms Delta = 277.296140ms Total = 2133.753080
Indx=5
Start = 8748.181720ms Delta = 302.946200ms Total = 2436.699280
Indx=5
Start = 10498.861540ms Delta = 269.732080ms Total = 2706.431360
Indx=5
Start = 11595.601440ms Delta = 316.445820ms Total = 3022.877180
Indx=5
Here is KMotionCNC running the same sequence (3.0 sec buffering)
Start = 0.000000ms Delta = 0.000000ms Total = 0.000000 Indx=6
Start = 570.692300ms Delta = 383.048120ms Total = 383.048120
Indx=21
Start = 1091.252500ms Delta = 28.897000ms Total = 411.945120
Indx=3
Start = 1936.351640ms Delta = 81.816000ms Total = 493.761120
Indx=124
Start = 2398.052420ms Delta = 26.737000ms Total = 520.498120
Indx=3
Start = 3244.501640ms Delta = 74.525900ms Total = 595.024020
Indx=122
Start = 3711.601980ms Delta = 26.462880ms Total = 621.486900
Indx=3
Start = 4564.801540ms Delta = 79.111740ms Total = 700.598640
Indx=122
Start = 5027.582000ms Delta = 17.282980ms Total = 717.881620
Indx=3
Start = 5884.021620ms Delta = 81.542300ms Total = 799.423920
Indx=122
Start = 6348.692420ms Delta = 14.586940ms Total = 814.010860
Indx=3
Start = 7128.721700ms Delta = 8.911900ms Total = 822.922760 Indx=4
Can we convince you to switch to KMotionCNC? It looks as if there
would be a significant time savings.
Regards
TK
On 6/12/2016 1:01 AM, Steve Blackmore
steve@... [DynoMotion] wrote:
On Sat, 11 Jun 2016 12:32:46 +0300, you wrote:
>Windows buffer time 3 seconds:
https://youtu.be/uGlA17TFJV4
>Windows buffer time 0.4 seconds:
https://youtu.be/WifaMpSrTb4
>Please excuse the instability in 3 sec video, caused
by chip hitting the camera man in the face.
>
>I tested running in simulation and it does not show
same delay as in real world.
>
>From what I have read on various posts this delay in
threading is present with most external controllers,
>this threading with mach/Galil:
https://www.youtube.com/watch?v=JfnQxDPWoEQ being only
exception I have found
>Threading starts at 1:38
Comparing apples to oranges there I think, the Galil uses
Ethernet, not
USB so buffer refresh rates are considerably quicker.
>I usually use G76 macro for threading, for the ease of
tweaking the measurements when needed, but several cross
checks show no difference in time/delay,
>so the delay is not due to mach3 macro handling.
Try it with G32 not macro.
Mach3 as with most other controls uses the index pulse as
the timer for
the start of the threading pass. It waits for the next
pulse before
issuing the next line. (From discussions a while ago and a
fading
memory- that might actually be two or three pulses to
ensure no false
trigger).
The thread pitch, diameter, spindle speed and lead in
distance all
affect the delay to some degree also.
Looking at your videos that looks normal for a USB control
with Mach.
Steve Blackmore
--
|
|
|
@@attachment@@
|
| Group: DynoMotion |
Message: 13352 |
From: bennyattwell |
Date: 6/13/2016 |
| Subject: Re: Mach3 lathe threading |
i have all the data here for the mach3 / galil threading the video shown was done with an ethernet controller. it uses plugin notifies to pass all required data to the galil. the galil handles all threading in a thread- with a program burnt into that thread when complete it hands control back to mach3
i have the mach macro and the .dmc threading program if its of any use. the .dmc program does all calculations for tapers etc etc
i know ken crouch spent years programming this to get it all to work as it does annoyingly i still havnt found the time to implement it into my lathe. |
|
| Group: DynoMotion |
Message: 13353 |
From: Tapio Larikka |
Date: 6/13/2016 |
| Subject: Re: Mach3 lathe threading [1 Attachment] |
Hi Tom,Steve&Brandon (thanks for chiming
in)
I have used both G32 and G76, main idea for trying
G32 was to see if G76 macro increases the delay due to the macro
interpretation.
To my understanding macros handle the movement
commads as if the were input to MDI on line by line basis.
Since I could not detect any difference I now use
G76 as it is easier to change measurements or number of passes as
needed.
There may well be measurable difference in millisec
but none to human eye.
Yes, when simulating means moving motors then the
delay should be visible
To my understanding common to all motion plugins is
that mach3 expects the plugin to handle whole threading operation, just sits and
waits for ready info.
I have understood that mach outputs linear and arc
moves as stream of setpoints and
corresponding time to get there, basically inverse time mode, but that threading
is different.
I found it interesting that threading pass and
pullout/retract move stay as continuous move regardless of the type/shape they
are:
G1, G2 as half circle at X-pullout distance, or G2
from endpoint of pass to starting point of next pass.
What would happen if you told Mach that threading
is complete right after its processed and sent to Kflop? Is it possible to
buffer the threading passes?
How far rigid tapping (NotifyMachTap) would be from
the approach Brandon said Galil uses?
I have been convinced to switch to KMotionCNC for a
while already. I'm just stuck with Mach for the time being because:
My lathe setup is gang tool so I need the Y-axis
and A-axis is used for spindle indexing needed to lock/unlock the 5C collet
based chuck you see on my video.
Partscounter/autorepeat work cycle/run till ref
qty
G-code macro generation
I could work around first two with user
programs, but last one needs mach style screen editor with scripting or
.net based front end.
Judging by my current progress with vb.net I guess
I'm ready sometime next decade :(
Rgds,
Tapio
| Group: DynoMotion |
Message: 13354 |
From: Tom Kerekes |
Date: 6/13/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tapio,
>>>To my understanding
common to all motion plugins is that mach3 expects the plugin to
handle whole threading operation, just sits and waits for ready
info.
Basically Yes. But that happens for
each pass. As well as for other motions and dwells.
>>>I have understood that mach
outputs linear and arc moves as
stream of setpoints and corresponding time to get there, basically
inverse time mode, but that threading is different.
The stream of points are equally spaced in time (2ms). Threading
is not really any different except that #1 when threading starts
the motion the motion should begin when the spindle is at a
certain orientation and #2 the motion (pseudo time) should be
geared proportionally to the spindle motion.
>>>>> face="Arial" size="2">What would happen if you told Mach that
threading is complete right after its processed and sent to
Kflop? Is it possible to buffer the threading passes?
I can't think of an easy way to do that because Mach3 expects to
stop and synchronize to the machine position at the end of the
sequence. I suppose it could all be faked but this would be
very complicated.
>>>> face="Arial" size="2">How far rigid tapping (NotifyMachTap)
would be from the approach Brandon said Galil uses?
I suppose that might work. A number of parameters much like G76
has could be passed to KFLOP C Program. Then the C Program
could create all the coordinated motions within KFLOP and
Trigger the Threading motions for the number of passes and so
forth. That way it would all happen in real-time with no
delays.
>>>> KMotionCNC size="2">G-code
macro generation
What are you referring to here? Something like a Mach3 Wizard
Screen?
Regards
TK
Hi Tom,Steve&Brandon
(thanks for chiming in)
I have used both G32 and
G76, main idea for trying G32 was to see if G76 macro
increases the delay due to the macro interpretation.
To my understanding macros
handle the movement commads as if the were input to MDI
on line by line basis.
Since I could not detect
any difference I now use G76 as it is easier to change
measurements or number of passes as needed.
There may well be
measurable difference in millisec but none to human eye.
Yes, when simulating means
moving motors then the delay should be visible
To my understanding common
to all motion plugins is that mach3 expects the plugin
to handle whole threading operation, just sits and waits
for ready info.
I have understood that mach
outputs linear and arc moves as stream of setpoints and corresponding time
to get there, basically inverse time mode, but that
threading is different.
I found it interesting that
threading pass and pullout/retract move stay as
continuous move regardless of the type/shape they are:
G1, G2 as half circle at
X-pullout distance, or G2 from endpoint of pass to
starting point of next pass.
What would happen if you
told Mach that threading is complete right after its
processed and sent to Kflop? Is it possible to buffer
the threading passes?
How far rigid tapping
(NotifyMachTap) would be from the approach Brandon said
Galil uses?
I have been convinced to
switch to KMotionCNC for a while already. I'm just stuck
with Mach for the time being because:
My lathe setup is gang tool
so I need the Y-axis and A-axis is used for spindle
indexing needed to lock/unlock the 5C collet based chuck
you see on my video.
Partscounter/autorepeat
work cycle/run till ref qty
G-code macro generation
I could work around first
two with user programs, but last one needs mach style
screen editor with scripting or .net based front end.
Judging by my current
progress with vb.net I guess I'm ready sometime next
decade :(
Rgds,
Tapio
| Group: DynoMotion |
Message: 13355 |
From: tapiolarikka |
Date: 6/13/2016 |
| Subject: Re: Mach3 lathe threading |
|
Hi Tom,
So as to simplify the problem is that where I want to make one thread in 5 passes
Mach makes 5 threads on one part and needs 5 times more time for resyncing and peddeling around.
I think then best solution for me would be to rewrite the G76 macro so that it passes the threading
parameters to user program (Notify msg 10076) and the user program handles the whole threading.
I am fairly confident on passing the parameters, but placing of commands to motion buffer and thread triggering
is above my skillset.
Would you happen to have an example/skeleton code?
Wizard? - Yes, much like mach wizards, just instead of using changing to wizard screenset, I added
extra page to my screen, where I have DROs for parameters and buttons to generate gcode based
on those parameters.
Rgds,
Tapio
|
|
| Group: DynoMotion |
Message: 13356 |
From: Tom Kerekes |
Date: 6/14/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tapio,
Performing Threading from a KFLOP C Program is the same as
Coordinated Motion (See the example CoordMotionInKFLOPTest.c also
attached) with the exception of instead of calling the ExecBuf()
function to start the motion with constant time base, call
TrigThreading(BaseSpeedRPS) that will sync to the spindle 0 degree
point before starting and progress based on the spindle motion.
Regarding the "Wizard" Screen: You could write a simple form in
C# that could run as a separate App that could pop up from a
KMotionCNC User button. The App could then create a GCode File
based on the form parameters, load it into KMotionCNC, and exit.
We have added a fair amount of "Automation" functionality into
KMotionCNC so other Apps written in other Languages can send
Messages to KMotionCNC to do things like loading a specified file.
I can provide more details if you are interested.
Regards
TK
Hi Tom,
So as to simplify the problem is that where I want to make
one thread in 5 passes
Mach makes 5 threads on one part and needs 5 times more
time for resyncing and peddeling around.
I think then best solution for me would be to rewrite the
G76 macro so that it passes the threading
parameters to user program (Notify msg 10076) and the user
program handles the whole threading.
I am fairly confident on passing the parameters, but
placing of commands to motion buffer and thread triggering
is above my skillset.
Would you happen to have an example/skeleton code?
Wizard? - Yes, much like mach wizards, just instead of
using changing to wizard screenset, I added
extra page to my screen, where I have
DROs for parameters and buttons to generate gcode based
on those parameters.
Rgds,
Tapio
|
|
|
@@attachment@@
|
| Group: DynoMotion |
Message: 13358 |
From: Tapio Larikka |
Date: 6/14/2016 |
| Subject: Re: Mach3 lathe threading [1 Attachment] |
Hi Tom,
I see said the blind man, or almost in my
case(starting to get age vision)
I had just figured out so much that there must be
an example I can use since KMotionCNC does threading, but time and agin I fail
to read through th c program files.
Apparently everything I can ask is already
there.
CoordMotionInKFLOPTest.c:
Coordsystem is already defined at init so this can
be left out?
VM would equal pitch in counts/sec at given
BaseSpeedRPS ?
Example places 4 moves in buffer and has one
execbuf() for all of them so do I then write:
openbuf
VM = pitch
linear
//threading pass 1
VM = 3*pitch //rapid for retract
speed
Arc
//retract move on XZ plane to the starting point of next pass
VM = pitch
linear
//threading pass 2
VM = 3*pitch //rapid for retract
speed
Arc
//retract move on XZ plane to the starting point of next pass
VM = pitch
linear
//threading pass 3
VM = 3*pitch //rapid for retract
speed
Arc
//retract move on XZ plane to the starting point of next pass
VM = pitch
linear
//threading pass 4
VM = 3*pitch //rapid for retract
speed
Arc
//retract move on XZ plane to the starting point of next pass
VM = pitch
linear
//threading pass 5
VM = 3*pitch //rapid for retract
speed
linear
//retract move out of workpiece
trigthread(basespeedrps)
while (!CheckDoneBuf())
Or does each pass need to be separated like:
openbuf
linear
//threading pass
VM = 3*pitch //rapid for retract
speed
Arc
//retract move on XZ plane to the starting point of next pass
trigthread(basespeedrps)
while (!CheckDoneBuf())
Example arc is on XY plane. How do I change it to XZ plane?
I return to the wizard subject when I get so far.
Regards,
Tapio
| Group: DynoMotion |
Message: 13359 |
From: Tom Kerekes |
Date: 6/14/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tapio,
See below
Hi Tom,
I see said the blind man,
or almost in my case(starting to get age vision)
I had just figured out so
much that there must be an example I can use since
KMotionCNC does threading, but time and agin I fail to
read through th c program files.
Apparently everything I can
ask is already there.
CoordMotionInKFLOPTest.c:
Coordsystem is already
defined at init so this can be left out?
>>>> Correct
VM would equal pitch in
counts/sec at given BaseSpeedRPS ?
>>>>> Correct
Example places 4 moves in
buffer and has one execbuf() for all of them so do I
then write:
openbuf
VM = pitch
linear
//threading pass 1
VM = 3*pitch //rapid for
retract speed
Arc
//retract move on XZ plane to the starting point of next
pass
VM = pitch
linear
//threading pass 2
VM = 3*pitch //rapid
for retract speed
Arc
//retract move on XZ plane to the starting point of
next pass
VM = pitch
linear
//threading pass 3
VM = 3*pitch
//rapid for retract speed
Arc
//retract move on XZ plane to the starting point
of next pass
VM = pitch
linear
//threading pass 4
VM = 3*pitch
//rapid for retract speed
Arc
//retract move on XZ plane to the starting
point of next pass
VM = pitch
linear
//threading pass 5
VM =
3*pitch //rapid for retract speed
linear
//retract move out of workpiece
trigthread(basespeedrps)
while (!CheckDoneBuf())
Or does each pass need to be separated
like:
openbuf
linear
//threading pass
VM =
3*pitch //rapid for retract speed
Arc
//retract move on XZ plane to the
starting point of next pass
trigthread(basespeedrps)
while (!CheckDoneBuf())
>>>> A TrigThread(basespeedrps) is required for each
pass as each pass needs to be triggered to start at the same
Spindle Angle
Example arc is on XY plane. How do I
change it to XZ plane?
>>>> You would need to reconfigure the Axes in the
Included routines. I can help with that but why do you want arcs
anyway? I'd recommend just doing Independent Rapid motions which
should be faster and utilize faster and smoother 3rd order motion.
I suggest:
#1 Rapid retract in X some amount
#2 when X moves enough begin rapid in Z
#3 When Z gets close begin rapid back in X
I return to the wizard subject when I
get so far.
>>>> I'm not sure if you are referring to a KMotionCNC
Wizard or your Mach3 "Wizard" Screen. Assuming the Mach3 Wizard
Screen - yes I would first get the multipass threading working with
hard coded values, then after it is working parameterize it with
your Wizard.
HTH
Regards
TK
| Group: DynoMotion |
Message: 13360 |
From: Tapio Larikka |
Date: 6/15/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tom,
Once again to see if I understood this
right
openbuf
VM = pitch linear
//threading pass
trigthread(basespeedrps)
while (!CheckDoneBuf())
openbuf VM = 3*pitch //rapid for
retract speed
linear X
// pullout
linear Z
// back to start of next pass
linear X
// start dept of next pass
ExecBuf while (!CheckDoneBuf())
Above repeated by number of passes
Some post on Mach forum I read said that Mach M
calls introduce small delay because Mach flushes buffer so
I presume there should be no conflict issues to
worry about when calling openbuf from user program. (conflicts with
plugin)
I suppose user programs only have point to point
moves available, no corner roundings (if not hardcoded as arcs) or
continuous velocity etc.
The arc as pullout/retract is/was to reduce jerk in
Mach trapezoidal system and to cut Mach macro commands from 3 to 1 in an
attempt
to reduce the delay. I dont have means to measure
the effect on axis accel but machine sounds much better
Regards,
Tapio
| Group: DynoMotion |
Message: 13361 |
From: Tom Kerekes |
Date: 6/15/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tapio,
I believe that is correct. Mach3 should flush all its buffers
and wait for all motion to complete before calling the Macro that
notifies the Plugin.
I think it would be simpler and faster to only use the
Coordinated motion technique only for the Threading. Then use
simple (overlapped) independent motions to do the motion back.
Like this:
openbuf
VM = pitch
linear //threading
pass
TrigThread(basespeedrps)
while (!CheckDoneBuf()) ; // wait for thread pass to finish
Move(X,A); // begin retracting in X
while (chan[X].Dest > Xp) ; // As soon as possible start Z
Move(Z,B);
while (chan[Z].Dest < Zp) ; // When Z gets close enough start
moving X
Move(X,C);
while (!CheckDone(X)) ;
Regards
TK
Hi Tom,
Once again to see if I
understood this right
openbuf
VM = pitch
linear
//threading pass
trigthread(basespeedrps)
while
(!CheckDoneBuf())
openbuf
VM = 3*pitch //rapid for retract speed
linear X
// pullout
linear Z
// back to start of next pass
linear X
// start dept of next pass
ExecBuf
while (!CheckDoneBuf())
Above repeated by
number of passes
Some post on Mach forum
I read said that Mach M calls introduce small delay
because Mach flushes buffer so
I presume there should
be no conflict issues to worry about when calling
openbuf from user program. (conflicts with plugin)
I suppose user programs
only have point to point moves available, no corner
roundings (if not hardcoded as arcs) or continuous
velocity etc.
The arc as
pullout/retract is/was to reduce jerk in Mach
trapezoidal system and to cut Mach macro commands
from 3 to 1 in an attempt
to reduce the delay. I
dont have means to measure the effect on axis accel
but machine sounds much better
Regards,
Tapio
| Group: DynoMotion |
Message: 13362 |
From: tapiolarikka |
Date: 6/15/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tom,  picture worth 1000 words, I'll come bak when I have some experience to share Thank you for help Tapio |
|
| Group: DynoMotion |
Message: 13399 |
From: Tapio Larikka |
Date: 6/29/2016 |
| Subject: Re: Mach3 lathe threading [1 Attachment] |
Hi Tom,
I got through my first step of passing the
parameters to user program.
but got stuck with the GetSpindleRPS.
Please see below code: enabling any of options 1 to
3 gives compiler error
Any idea why? Is GetSpindleRPS not available from
user program?
Rgds,
Tapio
#include "KMotionDef.h"
//Plugin calls for Mach3 NotifyPlugins
Commands
void Tap(void);
main()
{
int msg = persist.UserData[6]; // Mach3
notify Message 10000-10999
printf("Mach3 Notify Call, Message =
%d\n",msg);
if (msg==10076)
{
Tap();
}
}
void Tap(void)
{
// #10 1010 18
19 XEnd
// #11 1011 20
21 ZEnd
// #12 1012 22
23 Pitch
// #13 1013 24
25 H = Depth of first
pass
// #14 1014 26
27 I = Infeed
Angle
// #15 1015 28
29 R = XStart
// #16 1016 30
31 K = ZStart
// #17 1017 32
33 C = X
Clearance
// #18 1015 34
35 Complete
Flag
double XEnd = *(double
*)&persist.UserData[18];
double ZEnd = *(double
*)&persist.UserData[20];
double Pitch = *(double
*)&persist.UserData[22];
double H = *(double
*)&persist.UserData[24];
double I = *(double
*)&persist.UserData[26];
double R = *(double
*)&persist.UserData[28];
double K = *(double
*)&persist.UserData[30];
double C = *(double
*)&persist.UserData[32];
printf("XEnd = %f\n",XEnd);
printf("ZEnd = %f\n",ZEnd);
printf("Pitch = %f\n",Pitch);
printf("Depth of first pass =
%f\n",H);
printf("I = Infeed Angle =
%f\n",I);
printf("R = XStart = %f\n",R);
printf("K = ZStart = %f\n",K);
printf("C = X Clearance =
%f\n",C);
//printf("S = %f\n",GetSpindleRPS); //
option 1
//double S = GetSpindleRPS; // option 2
//float S = GetSpindleRPS; // option 3
//printf("S = %f\n",S);
}
| Group: DynoMotion |
Message: 13400 |
From: Tom Kerekes |
Date: 6/29/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tapio,
The Spindle related information is in the Spindle Object as
defined by the SPINDLE data structure in KMotionDef.h. So the
current speed would be printed with:
printf("S = %f\n",Spindle.TrueSpeedRPS);
HTH
Regards
TK
#include "KMotionDef.h"
//Plugin calls for Mach3
NotifyPlugins Commands
void Tap(void);
main()
{
int msg = persist.UserData[6];
// Mach3 notify Message 10000-10999
printf("Mach3 Notify Call,
Message = %d\n",msg);
if (msg==10076)
{
Tap();
}
}
void Tap(void)
{
// #10 1010 18 19
XEnd
// #11 1011 20 21
ZEnd
// #12 1012 22 23
Pitch
// #13 1013 24 25
H = Depth of first pass
// #14 1014 26 27
I = Infeed Angle
// #15 1015 28 29
R = XStart
// #16 1016 30 31
K = ZStart
// #17 1017 32 33
C = X Clearance
// #18 1015 34 35
Complete Flag
double XEnd = *(double
*)&persist.UserData[18];
double ZEnd = *(double
*)&persist.UserData[20];
double Pitch = *(double
*)&persist.UserData[22];
double H = *(double
*)&persist.UserData[24];
double I = *(double
*)&persist.UserData[26];
double R = *(double
*)&persist.UserData[28];
double K = *(double
*)&persist.UserData[30];
double C = *(double
*)&persist.UserData[32];
printf("XEnd = %f\n",XEnd);
printf("ZEnd = %f\n",ZEnd);
printf("Pitch = %f\n",Pitch);
printf("Depth of first pass =
%f\n",H);
printf("I = Infeed Angle =
%f\n",I);
printf("R = XStart = %f\n",R);
printf("K = ZStart = %f\n",K);
printf("C = X Clearance =
%f\n",C);
//printf("S = %f\n",GetSpindleRPS); // option 1
//double S = GetSpindleRPS; // option 2
//float S = GetSpindleRPS; // option 3
//printf("S = %f\n",S);
}
|
|
| Group: DynoMotion |
Message: 13413 |
From: Tapio Larikka |
Date: 6/30/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tom,
That worked.
I'm planning to do TrigThreaning(Spindle.TrueSpeedRPS) since
Mach already has spindle running.
Would this work or can you see some problem with
this?
Rgds
Tapio
| Group: DynoMotion |
Message: 13416 |
From: Tom Kerekes |
Date: 6/30/2016 |
| Subject: Re: Mach3 lathe threading |
Hi Tapio,
I think you need to use the Theoretical Spindle Speed which the
motion was planned for rather than the current speed. Otherwise
if the current speed was not exactly right there would be an error
in the Thread pitch.
I forget how your Spindle Speed Control works. But I believe you
should be able to save in a global persist variable the last
desired speed setting. Then use that.
Regards
TK
Hi Tom,
That worked.
I'm planning to do TrigThreaning(Spindle.TrueSpeedRPS)
since Mach already has
spindle running.
Would this work or can you
see some problem with this?
Rgds
Tapio
| Group: DynoMotion |
Message: 14656 |
From: Tapio Larikka |
Date: 4/29/2017 |
| Subject: Re: Mach3 lathe threading [1 Attachment] |
Hi Tom,
I finally got forward with this
threading.
Is there any way to set up a dummy/pseudo spindle
feedback?
I would feel more secure testing/debuging this kind
of codes with my spare kflop that is running open loop stepper
setup
with nothing connected to it?
Rgds,
Tapio
| Group: DynoMotion |
Message: 14658 |
From: Tom Kerekes |
Date: 4/30/2017 |
| Subject: Re: Mach3 lathe threading |
Hi Tapio,
I often simulate Spindle Feedback by configuring a Step/Dir
Generator to output Quadrature to pins on JP5 and then configure
the Spindle encoder input to the same pins.
Attached is the example configuration that configures Axis 6 in
that manner (set MySpindleDefs.h to use axis 6).
Regards
TK
Hi Tom,
I finally got forward with
this threading.
Is there any way to set up
a dummy/pseudo spindle feedback?
I would feel more secure
testing/debuging this kind of codes with my spare kflop
that is running open loop stepper setup
with nothing connected to
it?
Rgds,
Tapio
| Group: DynoMotion |
Message: 14679 |
From: Tapio Larikka |
Date: 5/6/2017 |
| Subject: Re: Mach3 lathe threading [1 Attachment] |
Hi Tom,
With the feedback and a bit tinkering
I now got this working in simulation, threading parameter transfer works as
well as the math for flank infeed.
As I started testing with real motions I noticed
strange behavior:
While movements both from mach jog and KMotion step
response work well on all speeds with minor (<400
counts) overshoot
on moves less than 6000counts
(10000/rev).
Strange thing is that with mach rapids ("G0X100" on
MDI) the axis behaves as if there was fluctuating load, sounding similar
to as if the
timing pulley was excentric to lead screw.
Have you heard of this kind of behaviour
before?
I the above difference makes me wonder if it
is mach or PC related as (if I have understood it correctly)
the mach jogs are more like native kflop moves
in nature where as the mach commanded moves make kflop chase
setpoint.
How would I go about testing if there is jitter in
setpoint stream that could cause this? Any guesses to cause are
welcome.
I'm running V4.33
Rgds,
Tapio
| Group: DynoMotion |
Message: 14680 |
From: TKSOFT |
Date: 5/6/2017 |
| Subject: Re: Mach3 lathe threading |
Hi Tapio,
I don't really understand your explanation. Fluctuating load?
It occurs at constant speed?
What type of system do you have? I assume Servos?
400 counts of overshoot seems large. What is your resolution?
You can use a C Program such as CaptureXYZMotiontoFile.c to capture the
exact trajectory that Mach3 is creating and how it is being generated by
KFLOP.
Regards
TK
On 2017-05-06 11:31, 'Tapio Larikka' tapio.larikka@...
[DynoMotion] wrote:
>
> Hi Tom,
>
> With the feedback and a bit tinkering I now got this working in
> simulation, threading parameter transfer works as well as the math for
> flank infeed.
>
> As I started testing with real motions I noticed strange behavior:
>
> While movements both from mach jog and KMotion step response work well
> on all speeds with minor (<400 counts) overshoot
> on moves less than 6000counts (10000/rev).
>
> Strange thing is that with mach rapids ("G0X100" on MDI) the axis
> behaves as if there was fluctuating load, sounding similar to as if
> the
> timing pulley was excentric to lead screw.
>
> Have you heard of this kind of behaviour before?
>
> I the above difference makes me wonder if it is mach or PC related as
> (if I have understood it correctly)
> the mach jogs are more like native kflop moves in nature where as the
> mach commanded moves make kflop chase setpoint.
>
> How would I go about testing if there is jitter in setpoint stream
> that could cause this? Any guesses to cause are welcome.
>
> I'm running V4.33
>
> Rgds,
> Tapio
>
>>
| Group: DynoMotion |
Message: 14681 |
From: Tapio Larikka |
Date: 5/6/2017 |
| Subject: Re: Mach3 lathe threading |
Hi Tom,
I mean chancing loaed like slip stick or offcenter
pulley causing the belt tension to alter.
Yes, it occurs on constant speed.
System is with dac driven ac servos, 10000
counts/rev, top speed set to 495000counts/sec.
mach buffer time 3sec.
overshoot is very small on step response graph. 400
counts is set max error and with no following error .
I'll try to take a carefull look at the graph to
figure out the actual overshoot.
I have the max errors fairly high to
compensate the difference caused by mach missing jerk
control.
I'll run the CaptureXYZ to see if there is
something.
Rgds,
Tapio
| Group: DynoMotion |
Message: 14686 |
From: Tapio Larikka |
Date: 5/7/2017 |
| Subject: Re: Mach3 lathe threading |
And here is the attachement
| Group: DynoMotion |
Message: 14687 |
From: Tom Kerekes |
Date: 5/7/2017 |
| Subject: Re: Mach3 lathe threading [1 Attachment] |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
? 